СУБД ЛИНТЕР для своей работы использует очереди таблиц, файлов, колонок и пользователей. Размеры очередей, задаваемые по умолчанию при создании БД, достаточны для работы, но не являются оптимальными. Поэтому для улучшения производительности рекомендуется настроить параметры очередей вручную или воспользоваться режимом автоконфигурирования.

Настроить параметры очередей можно в любое время после создания БД при остановленном ядре СУБД с помощью утилиты gendb или приложения «Администратор СУБД ЛИНТЕР».

Значения параметров размера очередей зависят от размеров создаваемой БД.

В СУБД ЛИНТЕР только очередь каналов является статической, остальные очереди – динамические.

Очередь является динамической, если при ее переполнении последний элемент очереди удаляется и замещается новым, т.е. происходит вытеснение элементов очереди.

Статическая очередь (т.е. очередь каналов) переполниться не может. Если СУБД настроена на работу с 5 каналами, то при попытке открыть 6-й канал клиентскому приложению, пославшему команду на открытие канала, будет возвращен соответствующий код завершения.

Размер любой очереди вычисляется как

< длина очереди > * < размер элемента очереди >

Размер элементов разных очередей колеблется в среднем от 50 до 1500 байт. Для поиска страниц в пуле ядра СУБД ЛИНТЕР используется механизм хеширования. Размер хеш-таблицы по возможности устанавливается равным числу страниц в пуле, но не больше 64 Кбайт. Память таблице выделяется во внутренней памяти ядра СУБД перед системными очередями. Хеш-значение вычисляется по номеру страницы и параметрам файла (номер таблицы, тип файла, номер файла).

Поиск свободной страницы в пуле ограничен просмотром не более 1/100 размера пула или 50-ю страницами (если размер пула меньше 5000 страниц), при этом поиск выполняется с учетом уровня страниц. Значение уровня странице присваивается на основе встроенного алгоритма оптимизации работы с пулом ядра СУБД (например, страницы индексных файлов имеют более высокий уровень по сравнению со страницами файла сортировки, поэтому вероятность их использования в качестве свободной страницы, т.е. вытеснение, ниже). После завершения поиска выбирается наиболее подходящая из просмотренных страниц.

Очередь таблиц

Очередь таблиц предназначена для хранения в пуле ядра СУБД системного описания таблиц, которые активно используются. В идеале в очереди таблиц должно содержаться описание всех таблиц БД. Если это невозможно, то имеет смысл проанализировать поток запросов к БД из клиентских приложений и определить количество и параметры наиболее часто используемых в SQL-запросах таблиц (усреднённый размер очереди).

В случае, когда размер очереди таблиц близок к этому усредненному значению, работа клиентского приложения будет, скорее всего, устраивать пользователя БД, и только в редких случаях могут возникать небольшие задержки. Таким образом, существует зависящая от клиентских приложений граница («пороговое значение»), характеризующее очередь как медленную или быструю. Если текущий размер очереди таблиц превышает эту границы, то клиентские приложения работают достаточно быстро, и дальнейшее расширение очереди таблиц практически не приведет к ускорению их работы.

При размере очереди таблиц меньше «порогового значения» (медленная очередь) скорость работы СУБД ощутимо снижается.

Очередь столбцов таблиц

Очередь столбцов таблиц предназначена для хранения в пуле ядра СУБД системного описания столбцов обрабатываемых таблиц.

Очередь столбцов является наиболее динамичной, поэтому ее размер существенно влияет на скорость обработки данных СУБД.

Если очередь столбцов слишком мала, то первые замедления в работе СУБД возникнут уже при трансляции SQL-запроса, поскольку транслятор проверяет корректность использования каждого столбца таблицы в транслируемом SQL-запросе путем обращения к СУБД за полным его описанием.

Ядро СУБД сначала ищет описания столбцов среди тех описаний, которые находятся в текущий момент в очереди столбцов. При этом для поиска находящегося в очереди элемента обычно нужно просмотреть в среднем половину очереди, а для того, чтобы установить отсутствие элемента, необходимо просмотреть всю очередь. Если дескриптор искомого столбца в очереди не найден, ядро СУБД ищет описание этого столбца в системной таблице описания атрибутов $$$ATTRI, где находятся описания всех столбцов всех таблиц БД. Если таблица $$$ATTRI не индексирована (по имени столбца), то поиск осуществляется простым перебором всех находящихся в нем описаний. Очевидно, это длительный процесс, особенно когда суммарное количество столбцов в БД довольно велико (средняя БД включает до 1000 столбцов).

Дескриптор найденного в таблице $$$ATTRI столбца включается в очередь столбцов, при этом из очереди столбцов вытесняется какой-то элемент (вполне возможно, что в этом случае понадобится еще и записать в БД информацию о вытесняемом столбце, если она изменилась). На этапе трансляции этот длительный (но разовый !) процесс обработки выполняется для каждого из использованных в SQL-запросе, но отсутствующих в очереди, столбцов.

Если бы процесс обработки SQL-запроса был непрерывным (или СУБД функционировала бы в однопользовательском режиме), то не возникало бы связанных с очередью замедления обработки, т.к. все необходимые столбцы уже находились бы в очереди и не вытеснялись бы из нее до окончания обработки запроса. Однако в многопользовательском режиме возникает потребность в параллельном выполнении нескольких SQL-запросов. При этом СУБД регулярно переключается на обработку очередного SQL-запроса, уделяя каждому из них квант обработки. Если размер очереди столбцов недостаточен, то описания столбцов текущего SQL-запроса могут вытеснить из очереди описания столбцов предыдущего SQL-запроса, и этот процесс будет повторяться для всех параллельно выполняемых SQL-запросов. Чем меньше квант обработки (чаще переключение между запросами), тем сильнее замедляется выполнение запросов.

Рекомендуется размер очереди столбцов задавать как можно больше. В идеале очередь столбцов должна вмещать описание всех столбцов всех таблиц БД.

Очередь файлов

При работе с таблицей БД ядро СУБД должно открыть файлы этой таблицы. Дескриптор открытого файла помещается в очередь файлов, вытесняя при этом, в случае необходимости, дескриптор другого файла с предварительной синхронизацией страниц файла в оперативной памяти и на диске.

Каждая таблица БД – это минимум два файла: файл данных и файл индексов. Данные/индексы могут размещаться в нескольких файлах (до 63). Таким образом, число файлов таблицы может быть до 63*2. При работе с таблицей ее файлы открываются только при необходимости. Чтобы начать работу с таблицей, СУБД открывает первый файл данных и первый файл индексов. Чаще всего пользователи БД размещают таблицу в двух файлах (один файл данных и один индексный файл). Разнесение таблицы более чем в два файла необходимо в редких случаях. Ниже приведен анализ эффективности работы СУБД в зависимости от размера очереди файлов.

Желательно, чтобы при работе с таблицей описания всех её файлов находились в очереди файлов. Таким образом, размер очереди файлов должен быть, как минимум, в 2 раза больше размера очереди таблиц, чтобы вместить описания одного индексного файла и одного файла данных каждой таблицы.

Если некоторые таблицы размещены более чем в двух файлах, то дополнительное увеличение очереди файлов не приводит к ощутимому росту эффективности клиентского приложения. Дело в том, что только первый индексный файл используется на протяжении всей обработки SQL-запроса, все остальные индексные файлы используются лишь для быстрого поиска записей по индексированному атрибуту. Команда «выдать следующую запись» уже не затрагивает остальные индексные файлы. При обработке SQL-запроса записи просматриваются порциями. Порядок просмотра почти совпадает с порядком поступления записей.

СУБД упаковывает данные, и добавляемая упакованная запись помещается на первое свободное место, достаточное для ее размещения. Эти свободные места («дырки») образуются практически случайно, однако замечено, что чем ближе процентное отношение среднего размера упакованной записи к среднему размеру неупакованной к значению 100 %, тем менее случайным становится процесс появления «дырок». Если СУБД считает информацию несжимаемой (процентное отношение среднего размера упакованной записи к среднему размеру неупакованной 100 %), то порядок расположения записей в файле будет почти совпадать с порядком их поступления на обработку. Таким образом, если очередная запись выборки данных извлекается из какого-либо файла данных, то следующие записи, вероятнее всего, будут в том же файле. Смена файлов в очереди файлов будет последовательной, что сделает работу СУБД в многопользовательском режиме более эффективной.

Если процентное отношение среднего размера упакованной записи к среднему размеру неупакованной близко к 100%, то увеличение очереди файлов вдвое по сравнению с очередью таблиц почти не даст повышения эффективности. Чем меньше процентное отношение среднего размера упакованной записи к среднему размеру неупакованной, тем больше вероятность переключения СУБД с одного файла на другой. Вполне возможно, что при маленьком процентном отношении среднего размера упакованной записи к среднему размеру неупакованной будет недостаточно очереди файлов вдвое большей, чем очередь таблиц (могут начаться ощутимые замедления). Однако это происходит только в том случае, когда таблицы состоят более чем из двух файлов.

Грубая оценка для требуемого размера очередей следующая:

Пример для утилиты gendb (в примере использованы произвольные числовые значения)

set database directory < путь к БД >;
set tables 100;
set columns 1000;
set files 200;
set users 200;

Установка очередей через интерфейс приложения «Администратор СУБД ЛИНТЕР»

Рисунок 1. Установка размера очередей

Более подробное описание можно найти в документации: